• Setiap kali mendengar istilah enkripsi pada AWS service, hampir pasti terkait dengan KMS
• AWS mengelola key enkripsi
• secara penuh terintegrasi dengan IAM untuk otorisasi
• Cara paling mudah untuk mengendalikan akses ke data
• Kelebihan menggunakan KMS:
  • dapat mengaudit setiap API call yang dibuat oleh key melalui CloudTrail
• KMS terintegrasi dengan sebagian besar AWS Service
  • EBS
  • S3
  • RDS
  • SSM
• Jika memiliki secret data, jangan pernah menyimpannya ke dalam plaintext, terutama ke dalam code
  • KMS dapat digunakan melalui API Call (SDK, CLI)
  • enkripsi secret yang disimpan di dalam code / environment variables

• KMS Keys merupakan nama baru dari KMS Customer Master Key
• Terdapat dua jenis KMS Keys
  • Symmetric (AES-256 keys)
    • 1 encryption key yang digunakan untuk enkripsi dan dekripsi
    • AWS Service yang terintegrasi dengan KMS menggunakan symmetric key CMK
    • Anda tidak dapat mengakses KMS Key Unencrypted (harus memanggil KMS API untuk menggunakan key)
  • Asymmetric (RSA & ECC Key pairs)
    • Memiliki dua jenis key
      • public (encrypt)
      • private (decrypt)
    • Digunakan untuk operasi encrypt/decrypt atau sign/verify
    • public key dapat didownload namun private key tidak dapat diakses secara plain
    • use case :
      • enkripsi di luar AWS oleh user yang tidak dapat memanggil KMS API

• Beberapa jenis KMS Keys
  • Customer Managed Keys
    • key yang langsung dibuat di KMS
    • User dapat mengelola : Create, manage and use ✅
    • Hanya digunakan untuk AWS Account yang bersangkutan ✅
    • Automatic rotation Optional (every 1 year) ✅
    • user dapat enable/disable
    • rotation policy dapat diatur
      • every year
      • old key preserved
    • Dapat menambahkan key policy (resource policy) dan audit di CloudTrail
    • menggunakan envelope encryption
  • AWS Managed Keys
    • digunakan secara eksklusif oleh AWS Service
      • aws/s3
      • aws/ebs
      • aws/redshit
    • User dapat view metada ✅
    • digunakan hanya pada AWS Account yang bersangkutan ✅
    • dikelola oleh AWS (secara otomatis rotated setiap 1 tahun)
      • user tidak dapat mengelola ❌
    • anda dapat melihat key policy dan melakukan audit pada CloudTrail
    • tidak dapat digunakan untuk operasi enkripsi diluar dari yang AWS lakukan
    • Automatic rotation :required ✅
  • AWS Owned Keys
    • dibuat dan dikelola oleh AWS digunakan oleh beberapa AWS service untuk melindungi resource
    • dapat digunakan oleh banyak AWS account, namun key tersebut digunakan secara internal
    • user tidak dapat view, use, track atau audit ❌
    • user tidak dapat mengelola key ❌
    • automatic rotation bervariasi

• Bagaimana me-create Key?
  • identifikasi source of the key material di KMS key
  • tidak dapat diubah setelah di-create (imutable)
• Ada tiga origin :
  • KMS (AWS_KMS) - default
    • AWS KMS secara otomatis create, dan manage key material di dalam key store
    • jenis origin, jika user membuat key melalui menu KMS, kemudian pilih create key
  • External (EXTERNAL)
    • import key material dari luar
    • user bertanggung jawab mengelola dan mengamankan key material di luar AWS
  • Custom Key Store (AWS_CLOUDHSM)
    • AWS KMS membuat key material di custom key store (CloudHSM Cluster)

• Pricing berdasakran Jenis key pada KMS Keys
  • AWS Owned Keys (free)
    • SSE-S3
    • SSE-SQS
    • SSE-DDB
  • AWS Managed Key (free)
    • aws/service-name
    • example:
      • aws/rds
      • aws/ebs
  • Customer managed keys, (created in KMS)
    • 1 usd/month
  • Customer managed keys, imported
    • haruslah symmetric key
    • 1 usd/month
• Pricing untuk API call to KMS
  • 0.03 usd/10.000 calls
• Terdapat fitur Automatic Key Rotation
  • AWS-managed KMS: otomatis rotasi tiap 1 tahun
  • Customer-managed KMS keys
    • harus diaktifikan
    • otomatis setiap 1 tahun
  • Imported KMS Key :
    • Hanya manual rotation yang dimungkinkan menggunakan alias

• KMS Key memiliki lingkup di satu region
• Case :
  • terdapat EBS volume yang dienkripsi dengan KMS di region A
  • Enkripsi menggunakan KMS key A di region A
  • Jika EBS volume tersebut ingin dicopy ke region B. Beberapa langkah berikut harus dilakukan :
    • Buat EBS snapshot dari EBS volume.
    • jika snapshot dibuat dari EBS volume yang dienkripsi, maka snapshot tersebut juga akan terenkripsi
    • Untuk mengcopy ke region B. snapshot tersebut perlu di-dekrip menggunakan KMS Key A
    • Copy ke region B
    • Enkripsi ulang menggunakan KMS Key B di Region B
    • Create EBS volume di region B dari snapshot EBS

• KMS Key policies adalah cara untuk mengendalikan akses ke KMS Key
  • mirip dengan S3 Bucket policies, namun perbedaannya jika tidak ada KMS key policy pada KMS Key maka tidak ada user yang dapat mengakses KMS key tersebut
• Dua jenis KMS Key Policy
  • Default KMS Key Policy
    • dibuat jika user tidak membuat specific KMS key policy
    • Default : mengijinkan semua orang di dalam account untuk dapat mengakses key
    • Digunakan jika anda memiliki IAM Policy yang mengijinkan semua user/role dapat mengakses key
  • Custom KMS Key policy
    • menetapkan user, role mana saja yang dapat mengakses KMS Key
    • define siapa yang mengadministrasi key
    • berguna untuk cross-account yang ingin mengakses KMS key

1. Buat snapshot yang terenkripsi dengan menggunakan KMS Key (CMK) pada Account A
2. Attach KMS Key policy untuk mengotorisasi cross-account access

{
	"Sid":"Allow use of the key with destination account",
	"Effect":"Allow",
	"Principal":{
		"AWS":"arn:aws"iam::xxx"
	},
	"Action":[
		"kms:Decrypt",
		"kms:CreateGrant"
	],
	"Resource":"*",
	"Condition":{
		"StringEquals": {
		"kms:viaService":"ec2.REGION.amazonaws.com",
		"kms:CallerAccount":"<TARGET-ACCOUNT-ID>"
		}
	}

}

Copy

3. share snapshot yang terenkripsi tersebut
4. Pada target account : buat copy dari snapshot pada point 3, dan enkripsi dengan CMK dari akun target
5. Buat volume dari snapshot pada langkah 4

//TODO

• Misal Primary Key pada region A, dan key ingin direplikasi ke region yang lain (region B, C, D)
  • key ID akan sama dengan primary key di region A (region asal)
• Mengapa memerlukan Multi-Region Keys?
  • KMS key yangs ama di lintas region dapat digunakan bergantian pada region tersebut
  • misal, enkripsi di region A, dan ingin dienkripsi di region B
  • multi-region key memiliki :
    • key id yang sama
    • key material yang sama
    • automatic rotation
  • Tidak diperlukan untuk melakukan enkripsi ulang / memanggil API lintas region
  • KMS multi-Region tidak sama dengan global
    • user memiliki key primary (dari region asal)
    • dan key replika di region tujuan
    • setiap key multi-region dikelola secara independen
    • hanya satu key primary dalam satu waktu, replica key dapat dipromosikan menjadi primary key-nya sendiri
  • Tidak direkomendasikan menggunakan Multi-region key kecuali pada use case yang sangat spesifik
    • karena KMS key seharusnya terikat pada satu region
  • Use case :
    • global client-side encryption
    • encryption pada Global DynamoDB
    • Global Aurora
    • Disaster Recovery
    • Active-active application yang dideploy lintas region